---
title: SAIF.Business.Tasks architecture
summary: Architectural responsibilities, boundaries, and interaction patterns.
status: draft
owner: SAIF Documentation
last_reviewed: 2026-08-21
library: SAIF.Business.Tasks
reference_type: embedded
---

# SAIF.Business.Tasks architecture

`SAIF.Business.Tasks` is a business/domain-layer class library in the SAIF BOF architecture that defines the shared task business-object contract, its dynamic search/filter subsystem, and a set of read-only task code-table lookups. It has no entry point, no UI, and no direct ADO.NET connection handling; it sits between the application layer (`SAIF.Application.Claim*`) and the SAIF BOF data portal.

## Responsibilities
- Define the abstract task business object (`clsTask`) and abstract task collection (`clsTaskCollection`), providing common persistence plumbing, properties, and rule wiring that concrete task types (e.g., in `SAIF.Business.Tasks.Claim`) extend with source-system-specific behavior.
- Assemble dynamic, criteria-driven `SELECT` queries against `TASK` via `clsTaskCollection.Criteria`, including bind-parameter management and Oracle `rownum` row-limiting/sorting.
- Route `TASK` create/update/delete through the Oracle stored-procedure package `pk82036_task`, keeping business objects free of direct connection handling.
- Provide read-only code-table lookups (`clsTaskActionCode`, `clsTaskCategoryCode`, `clsTaskPriorityCode`, `clsTaskSourceCode`, and their collections) that translate database code strings to/from framework enums (`TaskSourceSystem`, `TaskPriority`).
- Implement common task business rules (`clsTaskBusinessRules`) invoked by the BOF rules engine.
- Hold task "context" values (`clsTaskContext`) used to associate a task with an arbitrary business entity via category/code/date/numeric/text fields.

## Component boundaries
- `clsTask` / `clsTask.CriteriaBase`: abstract persistence boundary for a single task row — owns the `pk82036_task` stored-procedure names, request construction (`Before*`/`After*` lifecycle), and snapshot/restore state (`TaskStore`, `StoreValues`/`RestoreValues`).
- `clsTaskCollection` / `clsTaskCollection.Criteria`: dynamic-query boundary — the `Criteria` nested class is a self-contained SQL-assembly component that builds the base `TASK` `SELECT` plus ten `Format*` predicate helpers and an optional Oracle `rownum` outer wrapper.
- Code-table subsystem (`clsTaskActionCode`, `clsTaskCategoryCode`, `clsTaskPriorityCode`, `clsTaskSourceCode` and their collections): strictly read-only value-lookup boundary; all write-SQL properties throw `ApplicationException(clsConstants.Messages.InvalidSQLProperty)`.
- `clsTaskContext`: value-holder boundary for the six task "context" columns, with deep-copy support (`Duplicate()`).
- `clsTaskBusinessRules`: rule-layer boundary invoked by the BOF rules engine; notably `ValidSourceCategory` issues its own ad-hoc `SELECT COUNT(*)` directly against the data layer rather than delegating to the code-table objects — a cross-layer coupling the source flags as a `MUSTDO`.
- `Institutions` typed DataSet: compiled into this assembly but has no referencing code in the library — an apparently misplaced artifact*.

## Interaction model
- Canonical SAIF BOF pattern: a business object (`clsBusinessBase` subclass) exposes a nested `Criteria` class implementing `IBusinessCriteria` that owns the SQL; a `Before*` lifecycle method builds an `IDataRequest`, which is passed to `IDataPortalInfo.DataAccessLayer.ProcessPortalRequest`; an `After*` method then materializes the result.
- Business objects never open connections themselves — the caller-supplied `IDataPortalInfo` (DPI) is the sole database context for every operation.
- Two data-access styles coexist: (a) `clsTask` CRUD routed through the `pk82036_task` stored-procedure package with `CommandType.StoredProcedure`; (b) code tables and the task search collection use inline/dynamically-assembled SQL text.
- `clsTask` and `clsTaskCollection` are `MustInherit`; concrete subclasses (outside this library) supply `ActionCode`, `SourceCode`, `SourceSystem`, `DisplayField1..3`, `RequiresNotePadEntry`, `Load`, `PostFill`, `CopyTo`, `MarkCompleted`, and `NewTask`. `OverrideRules` lets descendants relax or approve a failing common rule.
- Every business type is `<Serializable()>`, consistent with remoting/session persistence of BOF objects across the web tier*.

## Architecture diagram
The following diagram shows the high-level component boundaries within `SAIF.Business.Tasks` and their relationship to callers and the data portal.

```mermaid
flowchart TD
	App["Application layer<br>(SAIF.Application.Claim*)"] --> Task["clsTask / clsTaskCollection<br>(abstract task business objects)"]
	Task --> Criteria["clsTaskCollection.Criteria<br>(dynamic SQL assembly)"]
	Task --> CodeTables["Code-table lookups<br>(clsTaskActionCode, clsTaskCategoryCode,<br>clsTaskPriorityCode, clsTaskSourceCode)"]
	Task --> Rules["clsTaskBusinessRules<br>(rule-layer)"]
	Task --> Context["clsTaskContext<br>(context value holder)"]
	Task --> DPI["IDataPortalInfo<br>(caller-supplied data portal)"]
	Rules -.->|"ad-hoc query, MUSTDO"| DPI
	DPI --> Proc["pk82036_task stored<br>procedures"]
	DPI --> InlineSQL["Inline SQL against TASK,<br>TASK_ACTION_CODE, TASK_CATEGORY_CODE,<br>TASK_PRIORITY_CODE, TASK_SOURCE_CODE"]
```

## Sequence diagram
The following diagram shows the primary retrieve-tasks request/response sequence (`clsTaskCollection.GetTasks`).

```mermaid
sequenceDiagram
	participant Caller as Application layer
	participant Collection as clsTaskCollection
	participant Criteria as Criteria (dynamic SQL)
	participant DPI as IDataPortalInfo
	Caller->>Collection: GetTasks(dpi, criteria)
	Collection->>Criteria: FormatRequest()
	Criteria-->>Collection: assembled SELECT + bind parameters
	Collection->>DPI: ProcessPortalRequest(IDataRequest)
	DPI-->>Collection: result rows
	Collection-->>Caller: clsTaskCollection
```

## Design constraints
- Business objects must never open database connections directly; all persistence flows through the caller-supplied `IDataPortalInfo`.
- Code-table objects are strictly read-only — attempting to use their write-SQL properties raises `ApplicationException(clsConstants.Messages.InvalidSQLProperty)`.
- `clsTask` and `clsTaskCollection` are `MustInherit`; this library never instantiates a concrete task type on its own.
- `TASK` create/update/delete is routed exclusively through the `pk82036_task` stored-procedure package; the DML statements themselves are opaque to this repository**.
- `clsTaskCollection.Criteria.WhereClause` returns `m_LastSQLStatement`, which is never assigned, because the private `FormatWhereClause()` that populates `m_WhereClause` is not called by `FormatRequest` — the property always returns an empty string, likely dead/legacy code*.

## Related documentation
- [Index](index.md)
- [Overview](overview.md)
- [Dependencies](dependencies.md)
- [Operations and processes](operations-processes.md)
- [Business rules](business-rules.md)
- [Database tables](database-tables.md)
- [SQL catalog](sql/index.md)
- [Procedures](procedures/index.md)
- [API reference](api/index.md)

> **Note:** Statements marked with * were inferred from code structure, naming conventions, or
> contextual evidence where direct confirmation was not available in source artifacts. Statements
> marked with ** could not be confirmed; treat as unknown until verified.

## Sources
- SAIF.Business.Tasks/clsTask.vb
- SAIF.Business.Tasks/clsTaskCollection.vb
- SAIF.Business.Tasks/clsTaskBusinessRules.vb
- SAIF.Business.Tasks/clsTaskContext.vb
- SAIF.Business.Tasks/clsTaskActionCode.vb
- SAIF.Business.Tasks/clsTaskActionCodeCollection.vb
- SAIF.Business.Tasks/clsTaskCategoryCode.vb
- SAIF.Business.Tasks/clsTaskCategoryCodeCollection.vb
- SAIF.Business.Tasks/clsTaskPriorityCode.vb
- SAIF.Business.Tasks/clsTaskPriorityCodeCollection.vb
- SAIF.Business.Tasks/clsTaskSourceCode.vb
- SAIF.Business.Tasks/clsTaskSourceCodeCollection.vb
- SAIF.Business.Tasks/SAIF.Business.Tasks.vbproj